home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
inet
/
iesg
/
93_04_15
< prev
next >
Wrap
Text File
|
1993-12-08
|
11KB
|
330 lines
IETF STEERING GROUP (IESG)
REPORT FROM THE IETF MEETING
April 15th, 1993
Reported by: Greg Vaudreuil, IESG Secretary
This report contains IESG meeting notes, positions and action items.
These minutes were compiled by the IETF Secretariat which is supported
by the National Science Foundation under Grant No. NCR 8820945.
For more information please contact the IESG Secretary.
iesg-secretary@cnri.reston.va.us.
ATTENDEES
---------
Bradner, Scott / Harvard
Chapin, Lyman / BBN
Coya, Steve / CNRI
Crocker, Dave / SGI
Crocker, Steve / TIS
Gross, Phillip / ANS
Hinden, Robert / SUN
Kahle, Brewster / WAIS
Knowles, Stev / FTP Software
Piscitello, Dave/ Bellcore
Rose, Marshall / DBC
Vaudreuil, Greg / CNRI
Regrets
Huizer, Erik / SURFnet
Mankin, Allison / Locus
Reynolds, Joyce / ISI
Stockman, Bernhard / SUNET/NORDUnet
IAB Liaison
Christian Huitema / INRIA
AGENDA
------
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of minutes
- April 8th
2. Protocol Actions
o X.400 Routing Coordination
o Distributed Authentication Security Service
3. Working Group Actions
o Modem Management (modemmgt)
o Character MIB (charmib)
o DECnet Phase IV MIB (decnetiv)
o AToM MIB (atommib)
4. Tasked Items
o RIP A/S
o Revised IPLPDN Working Group Charter
5. Management Issues
o Alignment of the Working Groups
o Informal operations review of Internet Drafts
o Compressing TCP/IP Headers
o DHC -- Status check
o Requirements for Draft Standard -
Implementation of the IESG policy
MINUTES
-------
1) Administrivia
o Approval of the Minutes
With corrections, the minutes of the April 8th teleconference were
approved.
o Next Meeting
In an effort to reduce the time demands on IESG members, the next
meeting was scheduled for April 29th.
2) Protocol Actions
o X.400 Routing Coordination
In the absence of Eric Huizer, this document was not reviewed.
o Distributed Authentication Security Service
The DASS work was submitted by the CAT work for consideration as an
Experimental Protocol. This effort was initially intended to be on
the standards track but the group has requested Experimental because
the development effort lost funding.
This work was originally developed within DEC and it is unclear
whether there are still intellectual property claims on this work.
Efforts were initiated to secure a letter of release but the current
status is unknown. As an experimental protocol a formal release is
not needed, but the RFC should indicate any Intellectual Property
rights claims on the content.
ACTION: Coya -- Inquire with Jon Postel and Vint Cerf about the current
requirements for the intellectual property rights declaration on
non-standards track RFCs.
ACTION: SCrocker -- Clarify with the authors of the DASS document the
status of any intellectual property right claims.
3) Working Group Actions
o Modem Management (modemmgt)
The IESG reviewed and approved the Modem Management Working Group
charter. This group met at the Columbus IETF meeting as a BOF. The
group intends to maintain liaisons with several external
organizations but has been discouraged from operating a lock-step
manner.
ACTION: Vaudreuil -- Announce the formation of the Modem Management
Working Group to the IETF list.
o Character MIB
The new Character MIB Working Group charter was approved. This
Working Group was rechartered to review the current standardization
status of the several character MIBs.
ACTION: Vaudreuil -- Announce the re-formation of the Character MIB
Working Group.
o DECNet Phase IV MIB
The new DECNet Phase IV MIB Working Group charter was approved.
This Working Group was rechartered to review the current
standardization status of the several character MIBs.
ACTION: Vaudreuil -- Announce the re-formation of the DECNet Phase IV
MIB Working Group.
o ATM MIB (atommib)
The IESG approved the charter for the ATM MIB Working Group. This
group is expected to be long lived given the evolving ATM standards
the many layers of the ATM protocol.
ACTION: Vaudreuil -- Announce the formation of the ATM MIB Working
Group.
The ATM MIB is one of several MIBs based on the aging Interfaces
group. The Interfaces group was written with a bit of a simplistic
model which does not work well with virtual circuit and tunneling
technologies. A new Working Group is being formed to revisit the
Interfaces group. The work of the ATM MIB group will be aligned
with the resulting new model and MIB.
4) Tasked Items
o RIP A/S
No progress to report.
o IPLPDN Charter.
Discussions on the future scope of the IPLPDN Working Group are
continuing.
5) Management Issues
o Alignment of Working Groups
Due to limited time in the IESG meeting, a review will be conducted
by email for approval of the current alignment of Working Groups
into the re-staffed IESG areas.
ACTION: Vaudreuil -- Send out the current Working Group summary to
confirm the current Working Group and Area alignments.
o Operational Requirements Review of Internet Drafts
An informal review of all Internet Draft is being conducted in the
Operations Area. This effort focus on evaluating the operational
impact of new proposals and feeding comments back to the authors.
This function is separate from but is expected to be included into
the scope of the Operations Area Directorate when finalized.
This review is being done on an experimental basis to gauge whether
the comprehensive review of proposals will have a benefits worth the
effort. Suggestions were made to publish a list of operational
criteria by which the proposals will be measured. Other ideas
included a dedicated section in the RFCs similar to the security
considerations section identifying possible operational impacts.
The IESG has discussed several "considerations" sections in the past
and discussion of the proposed "operational considerations" section
was deferred until a list of all such sections discussed by the IESG
could be gathered.
ACTION: Vaudreuil -- Get all the IESG discussions on various
"considerations" sections together for review at a future
teleconference.
o Compressing IP headers
Allison Mankin was not present to give a status update.
o Dynamic Host Configuration
The Working Group has worked out a few bugs and the area director
has pressed the group to get the current version out as a Proposed
Standard. The editing cycle is continuing too long. Revisions are
possible as the proposals go to draft standard.
o Requirements for Draft Standard
The IESG continued a discussion from the last meeting to refine the
requirements for a protocol to be advanced to Draft Standard. After
a bit of discussion, the following requirements was made.
POSITION: ALL protocols being considered for Draft Standard status
must have at least two implementations, each of which supports all
features and options and between which all features and options have
been tested. Features and options which have been speicified for
future use but which have not been tested must be removed from the
specification prior to advancement to Draft Standard.
The IESG earlier adopted a position that all protocols eligible for
advancement to Draft Standard be presented to an IETF plenary. With
the growing number of protocols, the growing size of the IETF
including mailing list only participants, the reduced frequency of
meetings, and the use of the last call procedure, this requirement
has been lifted.
POSITION: Unless requested by an Area Director, it is no longer
expected that a plenary presentation be made for each protocol under
consideration for Draft Standard.
Currently it is possible to standardize multiple competing
protocols. The IESG discussed the cost to vendors and providers who
must support each of the protocols and considered a proposal that
only one protocol for a given function be allowed to reach Standard
status. The IESG did not agree on this idea but did affirm that
the goal is to have one protocol per function. It may be reasonable
to have multiple protocols that perform a function such as a
generalized protocol with many features and a limited protocol
optimized for a particular situation.
o Wide Area Routing with RIP
This may be a topic for the routing work the IPLPDN Working Group
was originally chartered to do. The Internet Area agreed to review
the protocol analysis for assignment.
o Frame Relay Service MIB WG
The Frame Relay Service MIB effort will be defining managed objects
for service management, rather than device management--a new area
for IETF standardization. The IESG briefly discussed the proposed
working group scope and management along with the Competing
technical approaches that were being pursued. There was also
discussion on which area this effort should be placed under, who
should be named chair. The IESG agreed that the handling, to date,
was acceptable, and further agreed that this effort should be placed
in the Network Management area, with a neutral party named as
chair.
Appendix -- Summary of Action Items Assigned
ACTION: Coya -- Inquire with Jon Postel and Vint Cerf about the current
requirements for the intellectual property rights declaration on
non-standards track RFCs.
ACTION: SCrocker -- Clarify with the authors of the DASS document the
status of any intellectual property right claims.
ACTION: Vaudreuil -- Announce the formation of the Modem Management
Working Group to the IETF list.
ACTION: Vaudreuil -- Announce the re-formation of the Character MIB
Working Group.
ACTION: Vaudreuil -- Announce the re-formation of the DECNet Phase IV
MIB Working Group.
ACTION: Vaudreuil -- Announce the formation of the ATM MIB Working
Group.
ACTION: Vaudreuil -- Send out the current Working Group summary to
confirm the current Working Group and Area alignments.
ACTION: Vaudreuil -- Get all the IESG discussions on various
"considerations" sections together for review at a future
teleconference.
Appendix -- Summary of Positions Taken
POSITION: ALL protocols being considered for Draft Standard status
must have at least two implementations, each of which supports all
features and options and between which all features and options have
been tested. Features and options which have been speicified for
future use but which have not been tested must be removed from the
specification prior to advancement to Draft Standard.
POSITION: Unless requested by an Area Director, it is no longer
expected that a plenary presentation be made for each protocol under
consideration for Draft Standard.